Summary

Fixes a spurious nullCoalesce.offset error where $x[0] ?? null was incorrectly flagged as "always exists and is not nullable" after $x[0]['bar'] ?? null when the inner array type contained nullable values (e.g., list<array<?string>>).

Changes

• Added sideEffectSave flag to EnsuredNonNullabilityResultExpression to distinguish target saves (where null was actually removed) from side-effect saves (where the type was changed by recursive parent narrowing in specifyExpressionType)
• Modified ensureShallowNonNullability in src/Analyser/NodeScopeResolver.php to mark parent saves and early-return saves as side-effect saves, and track whether expressions existed in the original scope
• Modified revertNonNullability in src/Analyser/NodeScopeResolver.php to clean up spurious expression types after reverting: side-effect saves that didn't exist in the original scope are unset
• Added unsetExpressionType method to src/Analyser/MutatingScope.php for removing expression type holders without recursive side effects
• New regression test in tests/PHPStan/Rules/Variables/data/bug-13921.php and test method in NullCoalesceRuleTest

Root cause

When processing $x[0]['bar'] ?? null, ensureNonNullability calls specifyExpressionType to remove null from $x[0]['bar']. This method recursively narrows parent array types as a side effect, creating expression type holders for $x[0] and $x with Yes certainty. After processing, revertNonNullability restores the saved types using specifyExpressionType, which again creates recursive side effects. While ancestor types ($x) are properly restored by later entries in the save list, intermediate expressions ($x[0]) retain spurious Yes-certainty expression type holders.

The IssetCheck rule checks $scope->hasExpressionType($expr)->yes() as an alternative to $type->hasOffsetValueType($dimType)->yes(). The spurious expression type for $x[0] made this check return true, causing the false positive on $x[0] ?? null.

The fix distinguishes between target saves (the actual expression whose null was removed) and side-effect saves (expressions changed as a side effect of recursive parent narrowing). After reverting, side-effect saves that didn't have expression types in the original scope are cleaned up.

Test

Added regression test tests/PHPStan/Rules/Variables/data/bug-13921.php that reproduces the exact scenario from the issue: a function with list<array<?string>> parameter where $x[0]['bar'] ?? null is followed by $x[0] ?? null. The test expects no errors (empty expected errors array).

Fixes phpstan/phpstan#13921